In recent years, Wireless Local Area Network (WLAN) technologies have emerged as a fast-growing market. Among the various WLAN technologies, Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard is the dominating technology and is frequently used for WLANs.
Client devices within WLANs communicate with access points in order to obtain access to one or more network resources. An access point, referred to as an “AP,” is a digital device that operates as a gateway for a client device to establish a connection (e.g., a communicative coupling) with one or more networks (e.g., the Internet, an intranet, etc.). For example, an AP may be implemented as a wireless AP (WAP), which is configured to communicate wirelessly with one or more client devices as well as communicate with a networked device associated with the one or more networks, such as a controller for example, through a wired connection.
With respect to enterprise networks and other types of expansive multiple controller-based networks, conventional WLAN architectures do not manage controllers' resources efficiently. For instance, a client device that is communicatively coupled to a first AP may switch to a second AP due to a change in location of the client device, failure of the first AP, a better signal strength for the second AP, or for a number of other reasons. The second AP then determines whether to grant the client device access to one or more network resources.
When a client device switches from a first AP to a second AP, the first AP and second AP may be managed by separate controllers. Currently, the controllers do not forward data (e.g., state information) of transferred client devices. So, if by switching controllers, the client device crosses an Open Systems Interconnection (OSI) Layer-3 (L3) boundary, therefore switching IP subnets, a communication tunnel (e.g., a Generic Routing Encapsulation “GRE” tunnel) may be created between the first controller and the second controller. In this situation, the network traffic of the client device that is received via the second AP may be routed to both the second controller and to the first controller via the GRE tunnel. One advantage of this situation is that all of the state information and client sessions for the client device are maintained. However, the network traffic takes a longer path because it is routed through two controllers and two controllers are serving the client device therefore wasting network resources. Furthermore, a network-wide table is required to implement the tunneling system as each original controller must be maintained for each client device. This creates scalability issues as the number of client devices and controllers increases.
In a second situation, a client device may switch from a first AP to a second AP where the APs are managed by separate controllers but the controllers are in the same IP subnet (i.e., the client device does not cross a L3 boundary). In this situation, there is no mechanism to indicate to the controllers that a communication tunnel should be created between the first controller and the second controller. The second controller now manages the client device but the second controller does not have any of the state information of the client device. Therefore, the client sessions of the client device must be discarded, the client device must be re-authentication and the client sessions and state information must be recreated. This creates a disruption in the connection for the client device and wastes resources of the network because the state information of the client device previously existed.
Additionally, conventional multiple controller-based WLAN architectures support “client matching,” namely seamless matching of client devices with corresponding APs that are better able to provide network connectivity or communications as a whole with those client devices. For instance, according to conventional client matching techniques, a controller may attempt to direct a client device to a targeted AP within a first set of APs through a blacklisting function in which all APs controlled by the controller, except for the targeted AP, are precluded from associating with the client device. This may require the client device to disconnect from its current AP (e.g., transmit a De-authentication message in response to a prolonged connectivity disruption) and begin to seek to associate with another AP. When the controller performing the blacklisting function manages all of the APs this strategy is effective. However, if a second set of APs managed by a second controller is adjacent to the first set managed by the first controller, the client device may associate with an AP of the second set and disrupt the targeting process of the first controller. The first controller does not communicate with the second controller and therefore cannot notify the second controller of its intention to direct the client device to a particular AP.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.